Dynomotion

Group: DynoMotion Message: 9671 From: Sam Marrocco Date: 6/21/2014
Subject: Interpreter timing for raising events
The Interpreter.StatusUpdated event appears to return a first message with a line number of 0, yet all the other messages returned use line numbers of 1 to LastLineNumber. Is the message with LineNumber=0 a "first-status" status that is returned at the beginning of every Interpreter.Interpret() call and appears before any gcode lines are actually run?

I am attempting to use the StatusUpdated event to select the line in a GCode file display that is currently running on the Interpreter. Realizing that the OS is hardly realtime, is there some time discrepency/caching going on with the raising of events from the KFlop? If I run a series of short gcode commands totaling about 3 seconds of motion, the status messages for all lines have returned in less than a second--long in advance of the lines actually being run.

However, if I run a sequence of longer GCode commands, each taking 15 seconds, the StatusUpdated events returns nearly 3-6 seconds *after* the appropriate line has begun running.

In all cases, the very first status event for line 1 is always returned at the very start of line 1 running. The inconsistencies only appear for lines after line 1.

There is no code (on my end) that might be hanging--the events can notify me the instant they are raised. Even allowing for non-realtime performance, the delays seem very long. Is there another explanation?

--

sam marrocco | chief technical officer
ringside.cutters.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com
Group: DynoMotion Message: 9674 From: Tom Kerekes Date: 6/23/2014
Subject: Re: Interpreter timing for raising events
Hi Sam,

This has to do with the Interpreter working ahead for two reasons:  Trajectory Planning Look ahead and Windows/PC/USB latency.   If Windows temporarily "freezes" for some period of time enough motion must have been already Interpreted, Trajectory Planned, and buffered in KFLOP so the tool motion remains perfectly smooth.  In some cases this may require the Interpreter to be hundreds of GCode lines ahead.  You can specify the amount of time that should be buffered as:

        _Controller.CoordMotion.MotionParams.TPLookahead

Reducing this to a bit more than the maximum you ever expect your Windows box to "freeze" will minimize this issue.

Our Released Versions display all status based on the Interpreter's Look ahead State which can be confusing especially when offsets, modes, tools, etc have been changed within the look ahead time.

We have come up with a solution to this complex problem since Test Version 4.33a.  It involves keeping a complete history of the Interpreter State, reading from KFLOP it's current progress, and rewinding the Interpreter state to match the current machine tool state.  The code refers to this as "Real-time State Tracking" (maybe real-time is a bad name because it still isn't perfectly real-time, but should be as good as Windows can do).  If you watch the end of this video closely the KMotionCNC GCode line number is properly synchronized to the Machine tool position even while feeding forward and reverse.


That Version was described here.


This functionality seems to be working well, but we have not exposed it to the .NET interface yet.  We should have a Test Version that does that soon.   We have modified the DynomotionVB.net to display the current real-time line number as an example.  The .NET interface to the Interpreter state has been modified to automatically return the real-time state when a Job is in progress.  So for example the current real-time GCode Line number can be accessed as:

            _RealtimeLine = _Controller.CoordMotion.Interpreter.SetupParams.CurrentLine

I hope this explains what you are seeing.  The GCode line number is 0 based (Line 0 is the first line in the file).

Regards
TK




From: "Sam Marrocco SMarrocco@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Saturday, June 21, 2014 7:44 PM
Subject: [DynoMotion] Interpreter timing for raising events

 
The Interpreter.StatusUpdated event appears to return a first message with a line number of 0, yet all the other messages returned use line numbers of 1 to LastLineNumber. Is the message with LineNumber=0 a "first-status" status that is returned at the beginning of every Interpreter.Interpret() call and appears before any gcode lines are actually run?

I am attempting to use the StatusUpdated event to select the line in a GCode file display that is currently running on the Interpreter. Realizing that the OS is hardly realtime, is there some time discrepency/caching going on with the raising of events from the KFlop? If I run a series of short gcode commands totaling about 3 seconds of motion, the status messages for all lines have returned in less than a second--long in advance of the lines actually being run.

However, if I run a sequence of longer GCode commands, each taking 15 seconds, the StatusUpdated events returns nearly 3-6 seconds *after* the appropriate line has begun running.

In all cases, the very first status event for line 1 is always returned at the very start of line 1 running. The inconsistencies only appear for lines after line 1.

There is no code (on my end) that might be hanging--the events can notify me the instant they are raised. Even allowing for non-realtime performance, the delays seem very long. Is there another explanation?

--

sam marrocco | chief technical officer
ringside.cutters.picnic.moonlink

248 548 2500 w
248 910 3344 c

ringsidecreative.com